The ability to route calls in wireline networks based on calling-party location has existed for many years. In such wireline communications networks with location-based call routing, the calling party's number serves as the basis for determining the caller's location since the station (e.g., telephone) used to place the call resides at a fixed location. For example, many businesses serve customers throughout the United States and other parts of the world. These businesses have call centers distributed in different geographic locations and desire to have the calls distributed across these call centers. One method used is to route calls to the appropriate call center based on the calling party's location. “Appropriateness” may be determined by geographic proximity, political boundaries, or other criteria.
Another example of location-based routing that has existed for many years is emergency calls. Most countries mandate that a particular dialed number (e.g., 911 in the United States, 112 in many countries in Europe, etc.) be reserved and used explicitly for emergency calls. Once an emergency call is initiated using the particular emergency number, the communications network routes the call to the appropriate emergency call center for handling.
Unlike wireline networks, in wireless communications networks, the calling station may be mobile and therefore does not necessarily have a fixed location over time. Therefore, the wireless communications network must determine the station's location at the time of the call and use that as the basis for routing.
In the United States, the entity responsible for terminating, handling and responding to emergency calls is known as a Public Safety Answering Point (PSAP). At present, there are over 6,000 PSAPs throughout the United States. Currently, to test proper enhanced 911 (E911) routing and the delivery of call-related information (e.g., the caller's location) to the PSAP, the wireless communications provider must coordinate, with each affected PSAP in its operating territory, a time in which one or more test calls can be made. At the scheduled time, a technician makes a 911 call from a location served by the wireless network that needs to be tested. The call is routed to a PSAP, and a PSAP operator fields the call. The technician identifies himself or herself as conducting a test 911 call. The PSAP operator identifies which PSAP they are at and looks to see that the location of the technician's call appears on their console. If the call is routed to the incorrect PSAP or the location of the technician's call is not delivered, this is deemed a failure and the technician records this for subsequent analysis and troubleshooting. The time required to conduct a single emergency test call can last several minutes depending on the experience level of the PSAP operator. Further, test calls may have to be rescheduled due to higher priority tasks that must be handled by the PSAP (e.g., fielding emergency calls).
Practices for performing such tests are documented in ATIS-0500009 High Level Requirements for End-to-End Functional Testing from The Alliance for Telecommunications Industry Solutions. This document provides a sample form to be used to record call data and results for each test call. The form includes Test Call Conditions, Test Call Data, Information to Record from PSAP Display, and Pass/Fail information.
The Test Call Conditions are recorded prior to the test, that is, not collected during the testing. This data includes identifiers of the network equipment (cellular mobile switching center [MSC], wireline switch/selective router, and cell/sector) and Emergency Services Routing Digits (ESRD).
The Test Call Data includes call time, answering PSAP identifier and attendant name. This data and the pass/fail information are entered by the calling test technician based on local observations (time, pass/fail) and information received orally from the answering party (PSAP information).
The Information to Record from PSAP Display includes a number of data items received at the PSAP from the network, and is again entered by the calling technician based on oral information from the answering PSAP operator.
Thus the typical process has the following attributes.                Data is collected and consolidated at the calling location.        Much of the data is collected orally over the wireless link.        The data collection is labor-intensive, time consuming, and prone to error.        Data is available only from persons at the calling and receiving ends, that is, no data is necessarily collected by the equipment itself, and no data is collected from any of the network equipment (cellular or wireline).        
Wireless commercial location-based services which include routing calls to a destination based on the calling party's location are just beginning to emerge. The routing principles are, however, conceptually analogous to routing emergency calls.
One method of routing wireless calls is for the network to make the routing determination based on where the call enters the wireless network. Specifically, the location of the cellular base station (or other comparable wireless access point) antenna provides a gross estimate of the caller's position. For a sectorized base station with multiple antennas, the position estimate can be refined with knowledge of which sector the call originated on and the coverage area of each sector.
FIG. 1 shows a block diagram of a wireless communications network in which an emergency call is placed, according to prior art. Source devices 100, such as standard mobile handsets, are used by test personnel to place calls through the network 101. Rules 102 are used to allow the network to route the test calls to the correct destinations 103, for example Public Safety Answering Points. The test calls may utilize the actual emergency calling procedure (e.g., dial 911). Alternately a second set of rules is sometimes used (e.g., dial 922) so as to minimize the potential for impact on live emergency traffic. The rules are intended to route the calls to the proper destination, for example, the PSAP responsible for the area from which the call originated.
In any case, the data is then collected for post-processing. Test callers log their handset identification, calling time, calling location, and result of each call. The term “time” as used in this patent description refers to a specific and unique point in time. As such, it implicitly includes the date (month, day and year) as well as the specific time during the day. Call takers at the destinations may also log each call received, including handset identification, time, and any other data provided by the network, or alternately may provide this information orally to the test caller for logging. Test data can then be examined to evaluate network behavior.
Several problems are associated with the existing procedures.                Manually generated logs are subject to error. Not only can data be corrupted or lost through carelessness or oversight, but it is difficult for humans to accurately measure and capture certain metrics of interest, such as the exact duration from call request to call answer.        Tests are labor-intensive. Test callers are required as well as call-takers at the destinations. The availability of both test callers and call takers must be coordinated and scheduled in advance.        Testing can interfere with real emergency services, to the extent that the test calls share resources with live emergency calls. This is particularly true at the destinations, where communications trunks, call taking equipment, and human operators may be required to assume test functions while still servicing their primary functions. In the worst case, a call reporting a life-threatening emergency could be blocked by test calls. For this reason, it is often difficult to achieve the desired level of testing.        Test data is difficult to replicate. Because of difficulties in scheduling and performing tests, and collecting reliable data, comparative information on system performance over time is rarely available. This type of data could be used to predict system problems before they become critical.        
Therefore, there is a need for a method and system for automatically collecting data for performing call routing performance verification.